Data management system

ABSTRACT

A system comprises an input for product selection data; a marketplace product store for storing marketplace product definitions; a product selection store for storing data defining a selection of one or more products from the marketplace product store; an enterprise capability store for storing data defining capability of an enterprise in relation to supply of one or more products; and a product fulfillment data store for storing one or more product descriptions. At least one link is generated between each product description in the product fulfillment data store to data stored in the enterprise capability store, and at least one link is generated between each product description in the product fulfillment data store to data stored in the product selection store. The links are determined by a requirement in the respective product description for specified data in the enterprise capability store and the product selection store, such that a valid product description is dependent on presence of the specified data.

This application is the US national phase of international applicationPCT/GB01/01563 filed Apr. 5, 2001 which designated the U.S.

BACKGROUND

1. Field

The present invention relates to a data management system. It findsparticular application in supporting the provision of products orservices by one or more enterprises.

2. Description of Related Art

An information model is a model that describes the way that information,comprising data and rules, is defined, maintained, and used. Informationmodels are known in systems for the provision of products and services.

A good information model can facilitate effective and efficientintra-working and inter-working. Intra-working in this context refers tothe way that computer applications are organised and linked togetherwithin the context of a single enterprise. Inter-working refers to astructured means for those enterprises to work in a co-operative manner.The information model controls the way in which a system responds to arequest for a service or product, and manages that response.

SUMMARY OF EXEMPLARY NON-LIMITING EMBODIMENTS

According to a first aspect of the present invention, there is provideda data management system, for use in receiving and processing data inrelation to one or more products, and recording fulfillment in respectof a generated product description, the system comprising:

-   -   an input for product selection data;    -   a marketplace product store for storing marketplace product        definitions;    -   a product selection store for storing data defining a selection        of one or more products from the marketplace product store;    -   an enterprise capability store for storing data defining        capability of an enterprise in relation to supply of one or more        products; and    -   a product fulfillment data store for storing one or more product        descriptions;        wherein there is further provided means to generate at least one        link between each product description in the product fulfillment        data store to data stored in the enterprise capability store,        and at least one link between each product description in the        product fulfillment data store to data stored in the product        selection store        said links being determined by a requirement in the respective        product description for specified data in the enterprise        capability store and the product selection store, such that a        valid product description is dependent on presence of said        specified data.

According to a second aspect of the present invention, there is provideda method of managing data relating to product provision in relation tosupporting capabilities, which method comprises:

-   -   storing marketplace product definitions in a marketplace product        store;    -   receiving product selection data in relation to stored        marketplace product definitions;    -   storing data defining a selection of one or more products from        the marketplace product store in a product selection store, in        response to one or more received inputs;    -   storing data defining capability of an enterprise in relation to        supply of one or more products in an enterprise capability        store;    -   storing one or more product descriptions in a product        fulfillment data store; and    -   generating at least one link between each product description in        the product fulfillment data store to data stored in the        enterprise capability store;        wherein said at least one link is determined by a requirement in        the respective product description for specified data in the        enterprise capability store, such that a valid product        description is dependent on presence of said specified data.

A major driver for embodiments of the present invention is to improvethe responsiveness and flexibility of systems to create, implement, andsupport telecommunications products and services in an environmentcharacterised by rapid change and diversity.

BRIEF DESCRIPTION OF THE DRAWINGS

An information model and aspects of a management system built accordingto the information model are described below, as embodiments of thepresent invention, by way of example only, with reference to theaccompanying drawings in which:

FIG. 1 shows an overall layout for the model;

FIG. 2 shows a base class for the model;

FIG. 3 shows parameter defined classes and interactions in the model;

FIG. 4 shows an interaction stereotype for use in the model;

FIG. 5 shows role assignment for a party in the model;

FIG. 6 shows further details of role assignment according to FIG. 5;

FIG. 7 shows a role assignment pattern for use in the model;

FIG. 8 shows how parties are defined in the context of an organisationusing a role assignment stereotype;

FIG. 9 shows an object structure for defining parties, organisations androle assignment in that construction;

FIG. 10 shows a class diagram for the party concept in relation toorganisations and individuals;

FIG. 11 a class diagram similar to FIG. 10 but introducing partyidentification;

FIG. 12 shows an organisation chart that could be processed according tothe model to show the benefit of role assignment;

FIG. 13 shows a policy pattern for use in the information model;

FIG. 14 shows core agreement classes;

FIG. 15 shows possible sub-classes of the agreement class;

FIG. 16 shows association of parties to agreements;

FIG. 17 shows the construction and selection of marketplace products, inparticular in relation to product component fulfillment and enterprisecapability;

FIG. 18 shows classes comprising the enterprise capability concept;

FIG. 19 shows the construction of the relationship between the user,product component fulfillment and the agreement; and

FIG. 20 shows schematically an implementation of an embodiment of thedata management system.

DETAILED DESCRIPTION OF EXEMPLARY NON-LIMITING EMBODIMENTS

In the Figures and text below, the identifier “IA” is occasionally used.This stands for “Information Architecture” and is intended to mean thesame as the information model.

Referring to FIG. 1, an information model supporting embodiments of thepresent invention shows the following areas of information (“concepts”)that are fundamental to the operation of an enterprise, together withthe dependencies between them which determine how the management systembehaves in use.

Agreement 100

The information needed to support a formal or informal agreement betweentwo or more parties.

Rules 105

These may describe the policies enacted by concepts, the interactionsbetween their parameters, or the metrics applied when measuring theirperformance

Enterprise Capability 110

Enterprise Capability represents the information pertaining to what theenterprise is capable of delivering.

Event 115

Event represents the information pertaining to an occurrence of ahappening at a point in time—a change of state with which the enterpriseis concerned and the way in which these events are handled.

Financials 120

Financials represents any information concerning money or the managementof money that is of interest to the enterprise.

Location 125

Location represents any place, area or position that is of interest. Itrepresents the information needed to answer the question of wheresomething is, whether geographical or perhaps in an organisation orotherwise.

Market 130

Market represents the information about the environment in which theenterprise is selling, leasing or renting its marketplace products andthe activities undertaken to engage with these environments.

Marketplace Product 135

Marketplace Product represents the information about product offeringsmade to the marketplace and their selection. (Please note that in theclaims of this specification, the phrase “product definition havingassociated price data” is a reference to the Marketplace Product.)

Party 140

Party represents information about an individual or organisation and themany roles that they can take.

Product Fulfilment 145

Product Fulfilment represents information relating to the fulfilment ofa product selection.

User 150

The User concept represents an entity that is authorised by an Agreementto register with and use the Product Fulfilment covered by theAgreement. That entity may be an individual, a user group, anorganisation, or a system element.

The following describes the relationships between the areas ofinformation in use of an associated data management system.

Parties 140 (individuals or organisations) enter into Agreements 100with one another. When they do so they take on a role such as customer,supplier, distributor, etc. Parties may be located at Locations 125.

The enterprise offers Marketplace Products 135 to the Market 130.Parties 140 belong to a market segment within the Market 130. Thecustomer (a Party140 assigned a role within an Agreement 100) will makeselections from the options available as Marketplace Products 135 viathe Agreement 100 (defined in the data management system by an agreementdefinition). Selections made by a Party 140 from marketplace products135 specify what is provided for Users 150 and what is embodied in theProduct Fulfilment 145. The Agreement 100 grants permissions to theUsers 150 as to how they use the Product Fulfilment 145. As furtherdiscussed below, Parties 140 and Users 150 are defined and dealt withindependently.

All Marketplace Products 135 are based on the Enterprise Capability 110.The Product Fulfilment 145 must therefore be realised by the EnterpriseCapability 110. In order to direct the capabilities of the enterprise tothe Product Fulfilment 145, the Agreement 100 may provision theEnterprise Capability 110. The components that make up the EnterpriseCapability 110 may be located at a Location 125. Note that a User 150may be either human (i.e. a Party 140) or non-human (i.e. a component ofthe Enterprise Capability 110).

Events 145 are occurrences in which the enterprise is interested. Users150 may generate Events 115. The components that make up the EnterpriseCapability 110 may also generate Events 115. Events 115 may also bechanges of state to the Product Fulfilment 145, such as usage, withwhich the enterprise is concerned. Some Events 115 are chargeable andmay give rise to financial transactions, such as debits and credits,which may contribute to an invoice. The Agreement 100 also informs theFinancials 120 as to price policies, payment methods, invoice policies,etc.

Rules 105 are applied to all concepts. These may describe the policiesenacted by concepts, the interactions between their parameters, or themetrics applied when measuring their performance.

A data management system based on the above areas of information andtheir dependencies in use of the system displays several functionalitieswhich are advantageous. In particular, the way in which the followingareas of information are structured and interrelated providesadvantageous behaviour of the system in use:

-   -   parties, organisational construction, and the use of roles    -   the construction and selection of marketplace products, their        fulfilment and the link to the enterprises capabilities    -   user/customer separation and the relationship of a user with a        service fulfilment        Model Background

The above three areas are discussed in greater detail below. However,background to the model is as follows.

The information model is based on object-oriented software engineering.However, the information classes can be treated simply as datacontainers. In that case, the ‘methods’ applicable to the classes becomethe four methods known as CRUD: create—establishing an instance of theclass; read—retrieving the values of the attributes of the instance;update—changing one or more values of the attributes of the instance;and delete—removing the instance of the class.

Referring to FIG. 2, each of the classes inherits common data managementmetadata and methods to create, read, update, and delete.

The focus of the model is on the principal classes that represent theentities, events, and processes of an enterprise. However, it must alsotake into account the data, methods, and classes that give animplementation effort the proper guidance on combining operationalaspects with the principal classes to form a realized informationsystem.

To include the operational aspects, the information model employs thetechnique of defining a root class from which all classes of the modelinherit the common data management metadata and methods to create, read,update, and delete (CRUD). The root class, known as the IA Base class200, has two sub-classes. One sub-class, the IA Principal class 205, isthe root for the modelled information model classes, such as Agreementand User, and contains any common business attributes and methods thatwould be used across the visible information model classes. The othersub-class, the IA Auxiliary class 210, permits classes for audits,mapping external identifiers, etc. to be defined and associated with theIA Base 200 and, thus, be defined consistently across the entire model.

Each modeled class, Agreement through User 215, inherits from the IABase class 200 and IA Principal class 205 and adds its own businessattributes and business methods. This keeps the model focused oncapturing the business classes, methods, and relationships. The IA Baseclass 200 is assumed to be always present.

The model uses the known Unified Modeling Language (UML) as its syntax.An explanation of the UML syntax, and extensive overview of UML, can befound in “A guide to the UML Standard Notation” published on theInternet by the Rational Software Corporation athttp://www.rational.com/uml.

Pattern Classes and Relationships in the Model

Particular pattern classes and relationships that are found in the modelare:

-   -   Policy pattern class (indicated by <<Policy>>)    -   Parameter-defined pattern class (indicated by <<Parameter        Defined>>) including class-to-class Interaction.    -   Interaction pattern relationship (indicated by <<Interaction>>)    -   Role Assignment pattern relationship (indicated by        <<RoleAssignment>>)

A pattern class or relationship represents a group of classes fitting anenumerated pattern. The patterns are used to make the model easier toread. The most important of those mentioned here, for the purpose ofembodiments of the present invention, is the role assignment patternrelationship.

Policy Pattern Class (Indicated by <<Policy>>)

The policy definition which the information model uses is based upon thePolicy Framework defined by the Internet Engineering Task Force (IETF).(See the IETF Policy Reference Model published for instance on theInternet at http://www.ietf.org/html.charters/policy-charter.html.)

Referring to FIG. 13, a policy 1300 is applied using a set of policyrules 1310. Each policy rule 1310 consists of a set of conditions 1320and a set of actions 1315. The set of conditions 1320 associated with apolicy rule 1310 specifies when the policy rule is applicable. Policyrules 1310 may be aggregated into policy groups 1305. These groups maybe nested, to represent a hierarchy of policies 1300.

If the set of conditions 1320 associated with a policy rule 1310evaluates to TRUE, then the set of associated actions are executed. Forthe set of actions associated with a policy rule 1310, it is possible tospecify an order of execution, as well as an indication of whether theorder is required or merely recommended. It is also possible to indicatethat the order in which the actions are executed does not matter.

Policy rules 1310 themselves can be prioritized. One common reason fordoing this is to express an overall policy that has a general case witha few specific exceptions.

Policies 1300 can either be used in a stand-alone fashion or aggregatedinto policy groups 1305 to perform more elaborate functions. Stand-alonepolicies 1300 are called policy rules 1310. Policy groups 1305 areaggregations of policy rules 1310, or aggregations of policy groups1305, but not both. Policy groups 1305 can model intricate interactionsbetween objects that have complex interdependencies. Examples of thisinclude a sophisticated user logon policy that sets up applicationaccess, security, and reconfigures network connections based on acombination of user identity, network location, logon method and time ofday. Stand-alone policies 900 are those that can be expressed in asimple statement. Examples of this are VLAN assignments, simple YES/NOQoS requests, and IP address allocations.

Parameter-defined Pattern Class (Indicated by <<Parameter Defined>>)Including Class-to-Class Interaction

Referring to FIG. 3, a parameter defined class 305 is a complex type ofclass hierarchy used in the model. It is an aggregation of a set ofDefining Parameters 300. Each Defining Parameter 300 describes aparticular feature of the Parameter Defined Class 305. There may be anynumber of Defining Parameters contributing to the Parameter DefinedClass. It is modeled in this way to allow maximum flexibility in the wayin which the capabilities of the Parameter Defined Class are built.

Each of the Defining Parameters 300 may interact with one or more of theother Defining Parameters. The <<Interaction>> relationship pattern 310defines the nature of this interaction.

Interaction Pattern Relationship (Indicated by <<Interaction>>)

Referring still to FIG. 3, there are a number of classes in the model inwhich the objects of a class may have interactions with other objects ofthe same class. This interaction is indicated with the class having arelationship to itself and stereotyping the relationship as an“Interaction” 315. This would appear for any class of the model as shownin FIG. 3.

The Interaction stereotype 315 represents an associative class and itssub-classes that capture the types interactions and their details. Itcommunicates the existence of these classes without having the clutterdistracting from the more important aspects of the model. Referring toFIG. 4, the Interaction stereotype is used in the model as a short handto indicate the presence of the pattern of classes and relationships asshown.

In this pattern, the AnyClass Interaction 400 captures the interactiondetails between Object A and Object B of the AnyClass 405. Theinteraction is not mandatory—it is permissible that an object withinAnyClass does not have any interaction other objects within AnyClass.

Sub-classes are used to enumerate the types of interactions supported.The interaction types enumerated are not the comprehensive list ofpossible interactions. The sub-classing serves as the addendum point atwhich other interactions are to be added as they are discovered. Thesub-classes of the AnyClass Interaction include the following:

-   -   AnyClass Exclusivity 410—defining a mutually exclusive        relationship between AnyClass Object A and Object B.    -   AnyClass Migration 415—defining a migration of AnyClass Object A        to Object B.    -   AnyClass Substitution 420—defining a substitution of AnyClass        Object A for Object B.    -   AnyClass Dependency 425—defining a dependency of AnyClass Object        A on Object B.        Role Assignment Pattern Relationship (Indicated by        <<RoleAssignment>>)

Referring to FIG. 5, there are many classes in the model in whichParties are assigned to a responsibility associated with that class. Theresponsibilities associated with a class are captured by the roles forthe class. This is indicated with Class 405 having a relationship toParty 505 and stereotyping the relationship as a “RoleAssignment” 500.This would appear for any class in the model.

Referring to FIG. 6, the RoleAssignment stereotype 500 represents a setof classes and relationships that capture the AnyClass ownership ofroles and the assignment of Parties to those roles. In this pattern,AnyClass 405 refers to any class in the model. An object within AnyClass405 may have zero or more roles defined with it. The roles are capturedin the AnyClass Role class 600. An object of the AnyClass Role class 600can be associated with one and only one object in AnyClass 405. A Partymay be associated to zero or more roles in AnyClass Role 600. A role mayhave zero or more Parties 505 associated with it. Each Party/rolerelationship is an Assignment 605 that has its own descriptiveattributes, such as start date, end date, type (temp/permanent), andstatus (inactive, active). The assignment and role are dependent on theAnyClass 405. That is, if an object in AnyClass 405 is deleted, itsassociated roles and assignments are meaningless and should be deleted.

Referring to FIG. 7, as an example, there may be a role assignmentpattern that is formed for the relationship between Party 505 and HumanActivity 700. The relationship is labeled with the stereotype of<<RoleAssignment>> 500. The naming convention for the specific classesof this pattern is to substitute the name of the role owning class forAnyClass 405. Thus, by substituting “Human Activity” for Anyclass forall the classes in the pattern, the model segment shown in FIG. 7 isimplied.

Parties, Organisational Construction, and the Use of Roles

FIG. 8 shows how parties 505 are defined in the context of anorganisation 800, including the use of the <<RoleAssignment>> stereotype500.

FIG. 9 shows the <<RoleAssignment>> stereotype 500 expanded. The objectstructures show how parties 505 are defined in the context of anorganisation 800, the way in which organisations 800 are constructed andthe way in which parties 505 are assigned to roles 905 within thatorganisation 800. The Organisation class 800 holds the data about agroup. The Individual class 815 holds the information about a singleperson. The Party class 505 captures the fundamental information commonto both. The generalised Party class also allows associations to otherclasses to be more easily portrayed and understood.

A party 505 is defined as either an individual 815 or an organisation800. Any one instance of Party 505 is a single instance of anOrganisation 800 or an Individual 815. Party allows for a generalreference to both Organisation 800 and Individual 815. An organisation800 consists of one or more organisation roles 905. For eachorganisation role 905, there may be a party 505 assigned to fulfil thatrole. Whenever this is the case, the nature of the relationship betweenthe party and the organisation role 905 is defined as an organisationassignment 910.

The notion of a group is captured in the model by the Organisation class800. An Organisation 800 can be one of many types. Some of these typesrequire the model to capture knowledge of unique characteristics forthat type. Typical organisation types and sub-types would be:

Organisation Type Potential Sub-types Organisation Internal unitStatutory Organisation Government, Association, Enterprise HouseholdGovernment Agency. Military Branch Enterprise Non-Profit,Proprietorship, Corporation

The use of structures such as this to model the complexities oforganisations and their constructions allows the management oforganisation data to be made more efficient. Organisations tend todescribe themselves in terms of sub-organisations and positions whichindividuals take on. For example, an organisation may have a ChiefExecutive Officer, Chief Technology Officer, Chairman, etc. Thestructure shown in FIG. 9 allows these roles to be defined,independently from the individuals who may be assigned to them. It alsoallows individuals to take on one or more roles (even within oneorganisation 800) and it allows the nature of the assignment 910 (e.g.for a given period of time) to be defined as part of the organisationalmake-up.

Without this powerful construction, data management systems would berequired to un-build and re-build data associated with each individualand how they fit into an organisation, every time there is anorganisation change. This construction prevents the need for this andenables efficient data management practice to be put into place.

Referring to FIGS. 8, 9 and 12, as an example of the role assignmentclass in use, an organisation such as British Telecommunications mighthave an organisational chart that sets out a hierarchy of specifiedroles 1200, some of which have been assigned to individuals 1205. Atleast one of these assignments has an associated description 1220 offactors in the role assignment such as term, and time to be allottedover each working year. For instance, the CTO (Chief Technology Officer)is an object of the class Organisation Role 905. In FIG. 12, this rolehas been allocated to the individual Sam Brown 1205, represented in theinformation model as an object of the class Party 505, in this case anobject of the class Individual 815. The nature of the assignment, givenby the associated description 1220 of factors, is represented by anobject of the class Organisation RoleAssignment 905/910.

If the individual allocated the role of CTO changes, then a new objectof the class Party 505 will be substituted and it may not be necessaryto make other changes. However, the Organisation RoleAssignment 905/910can be independently changed. For instance, Sam Brown may have accepteda change from a temporary to a permanent post in the role CTO. This willappear in a model of the organisation as a change in the OrganisationRoleAssignment 905/910 but it is not necessary to make any changes inthe Party object for Sam Brown which could be a complicated exercise.

FIG. 10 shows the complexity which can be involved in numerousassociations to Party 505, via the <<RoleAssignment>> stereotype 500. Ifthese associations were to be with Individual 815 and Organisation 800separately, the model would soon be unreadable. The Party 505 could evenfacilitate implementing the regulations of the European Data ProtectionAct by acting as the focal point for data concerning the Organisation800 and Individual 815.

Referring to FIG. 11, a Party 505 represents an Individual 815 orOrganisation 800 which has a relationship with the business. There aremany ways of identifying a Party, some unique, e.g. Driver's Licensenumber, National insurance Number, and some non-unique, e.g. name. Inaddition, there are the credentials that a party must have to be able toengage in commerce, such as tax ID, DUNS Number, SIC Code, TaxExemption. The model represents all these attributes through the PartyIdentification class 1100.

Agreement Concept

In the course of daily commerce, a Party may wish to strike accords withother Parties. These accords are modelled as Agreements. The coreAgreement classes are shown in FIG. 14.

Referring to FIG. 14, the structural definition of an agreement involvesthree classes: Agreement 1400, Agreement Role 1405, and Agreement Item1410. The Agreement class 1400 serves as the centre point for theinformation about an agreement. It contains descriptive data and the“when” information (start date, end date). The Agreement Role class 1405captures the functional positions outlined by an Agreement. The modelrequires at least two Agreement Roles be defined for an Agreement. Theseroles would be the principals for which the agreement exists. TheAgreement Item class 1410 represents the “what” of an agreement. Themodel requires at least one Agreement Item be in existence for eachAgreement.

There are two aggregations of Agreement to the Agreement class 1400 inthe model. The one labeled “ContainedAgreement” 1415 allows for thenotion of “master agreement/sub-agreements” to be supported. The onelabeled “RevisedAgreement” 1420 represents the linking of revisions ofan Agreement back to its predecessors and the original.

Referring to FIG. 15, an Agreement 1400 can be one of many types. Someof these types possess unique characteristics that a model must capturein use. The model records this uniqueness by sub-classing Agreement intoBid 1500, Contract 1505, and Order 1510 classes. As more Agreement typesare needed, the model can be extended via sub-classing.

Agreement Assignment

Referring to FIG. 16, when two Parties 505 enter into an Agreement 1400,it is in reality an accord between the two Parties to play certain roleswithin a relationship concerned with exchanging service or goods. Thelink between Party 505 and Agreement Role 1400 captures the role thatthe Party is playing within a specific Agreement 1400.

An Agreement Role 1400 can be one of many functional positions, some ofwhich are enumerated by sub-classing Agreement Role into Customer 1605,Supplier 1610, Distributor 1615, Guarantor 1620 and Prospect 1625classes as shown. As new Agreement Role types are needed, the model canbe extended via sub-classing. The Agreement Roles required aredetermined by the Agreement and may be different for each Agreement.

The Agreement Role 1405 defines what the functional positions are withinthe Agreement, while the Agreement Assignment 1600 defines who isassigned that position. The Agreement Assignment class 1600 captures thetimeframe and status of a Party 505 playing a specific Agreement Role1405. For each Agreement Role 1405 in which a Party 505 is involved,there will be an Agreement Assignment object 1600 created.

For example, an Agreement may specify that there is to be a customercontact. For the first three months, Gerard Wiekens was the customercontact. Since then, Andy Morrison has been the contact.

-   -   The Agreement 1400 has an Agreement Role 1405 defined for        “customer contact.”    -   The Party 505, Gerard Wiekens, has an association with Agreement        Role “customer contact” recorded as an Agreement Assignment 1600        for Gerard with the status of “active”.    -   In three months, the Party 505, Andy Morrison, takes over the        job. An association with Agreement Role “customer contact” is        recorded as an Agreement Assignment 1600 for Andy with the        status of active.

The Agreement Assignment 1600 for Gerard, associated with the AgreementRole 1405 of “customer contact”, has its status marked “inactive”.

Agreement Item

Referring to FIG. 17, the Agreement Item class 1410 represents a lineitem within an Agreement 1400. An Agreement must have at least oneAgreement Item. Each Agreement Item 1410 specifies a Marketplace Product(MPP) 1700 to be purchased/provided and the quantity of that MPP. AnAgreement Item 1410 may only be associated with one specific MarketplaceProduct 1700, but it may indicate 1-to-many instances of thatMarketplace Product's components.

Marketplace products (MPPs) 1700 are offered to the marketplace inresponse to a market demand. A supplier undertakes to provide an MPP1700 to a customer as a result of some contractual agreement. In sodoing, the MPP 1700 is bound to the agreement as an agreement item 1410.The MPP will be made up of one or more product components 1705. When thecustomer specifies the MPP in the agreement 1400 he/she will make aproduct selection which will consist of one or more componentselections, as determined by the choices the customer makes. Thecomponent selection 1715 must be dependent on the product component 1705to which it refers. That is, it should not be possible for a customer tochoose a component that is not on offer as part of that MPP 1700.

The following two examples illustrate the Agreement concept discussed tothis point:

-   -   1. Mark Kennedy has sold a computer, on behalf of his employer,        IBM, to Kevin Horlock:        -   The Agreement is an accord for exchanging money for goods.        -   The computer (one of the MPPs 1700 which IBM offers) would            be referred in the Agreement Item 1410.        -   The specifications of the computer (RAM, disk size, etc) are            captured in the Component Selection 1715 and aggregated into            Product Selection 1710.        -   Kevin Horlock is a Party/Individual 505/815 with the            Agreement Assignment 1600 of Customer.        -   IBM is a Party/Organisation 505/800 with the Agreement            Assignment 1600 of Supplier.        -   Mark Kennedy is a Party/Individual with the Agreement            Assignment of “Salesperson.”    -   2. A head of household enters into an Agreement 1400, in order        to obtain Email service for a child:        -   The Agreement is an accord for exchanging money for the            Email service.        -   The Email service would be represented as a Marketplace            Product 1700 in the Agreement Item 1410.        -   Each separate specification for the Email service is            captured by Component Selection 1715 and these in turn are            aggregated to a Product Selection 1710 of ‘Email Service’.        -   The parent is a Party/Individual 505/815 with the Agreement            Assignment 1600 of Customer 1605.        -   The service provider is a Party/Organisation 505/800 with            the Agreement Assignment 1600 of Supplier 1610.        -   The child is a Party/Individual 505/815 with the Agreement            Assignment 1600 of ‘Grantee’.

The Marketplace Product 1700 and its related classes allow theenterprise to create products for the marketplace in terms of theProduct Component 1705. The Product Component 1705 represents a cohesiveunit of deliverable product that has business and/or technical meaning,such as email service and address book. The Product Component class 1705is a “Parameter Defined” class which may also have an <<Interaction>>relationship, of one component to another. Components are configuredinto a Marketplace Product 1700 in allowable combinations where theProduct Component Interaction allows dependencies, one component toanother. The parameters used to define Product Component 1705 representcharacteristics that define the component to the marketplace andtechnical requirements to be supported by the enterprise. Suchparameters may state “1 email administrator required” or “1 gatewayserver required”. Additionally, the parameters can express productconfiguration choices, such as “e-mailbox size: 50M or 60M”

In time, the supplier will fulfil each component selection 1715 as aproduct component fulfilment (PCF) 1720. The PCF defines what thecustomer actual receives. The PCF 1720 will be dependent upon thecomponent selection 1715. That is, it should not be possible for thecustomer to receive a PCF that is not based upon a chosen componentselection 1715. For the supplier enterprise to fulfil the selection itmust have the enterprise capability to deliver. Each PCF 1720 will bedependent upon existing or planned enterprise capability 110.Furthermore, the product components 1705 offered to the marketplace willalso be dependent on existing or planned enterprise capability 110.

The use of this construction has a number of benefits to an enterpriseseeking to manage the data relating to commerce with its tradingpartners:

-   -   It ensures that there is an audit trail between offers to the        marketplace, the trading agreement, the customer's selection,        the fulfilled order, and the ability of the supplying enterprise        to deliver.    -   It allows a modular approach to product construction, making for        efficient re-use of enterprise resources.    -   It allows an enterprise to offer products to the marketplace but        bring to bear changing capabilities in how it delivers to its        customers. This allows for technology swap-out without impact on        customer service.    -   It allows the separation of data relating to the offer, the        request and the fulfilment. This enables an enterprise to        provide substitutes (subject to customer agreement) where        efficient operation dictates, while maintaining the data for the        original request.

Referring to FIG. 17, there is a dependency relationship betweenEnterprise Capability 110 and Product Component 1705. This representsthe constraints the Enterprise Capability parameters must have on theProduct Component parameters. This is to ensure that products are notdefined for which there are no present or planned capabilities. In anexample, a Product Component parameter cannot state “number of addressbook entries: 500 or 1000 or 1500” if the corresponding EnterpriseCapability parameter states “number of address book entries must be lessthan 1000”.

The Marketplace Product 1700 uses the Product Component 1705 to giveflexibility to the creation of offers to the marketplace. For example,if Microsoft Word™, Excel™, Access™, and PowerPoint™ are ProductComponents, then a Marketplace Product of “MS Office™” may be created.In addition, all of these may be offered individually as MarketplaceProducts 1700. To further combine these with consulting or educationclasses, a Product Component 1705 for consulting and one for educationmay be created. These can now be combined with the Product Components toform new Marketplace Products 1700 that include the service(consulting/education) and product (“Office”).

Referring to FIG. 18, The Enterprise Capability concept represents theability of an enterprise to offer products and services based upon itsabilities (Enterprise Capability class 110) and the activities thatensure that the capabilities are suitably configured. The classes thatcomprise the Enterprise Capability concept are shown in FIG. 18.

An enterprise's Marketplace Products 1700 are built upon thecapabilities available to the enterprise. These capabilities must havestaff and technical prowess to deliver them once a Marketplace Productis sold. In FIG. 18, the Enterprise Capability represents the range ofall the product-forming and product-impacting capabilities of theenterprise. It is categorized into two general groups:

Infrastructure Capability 2000—represents all of the abilities providedby the technical infrastructure, such telephony, IP services, routers,telephones, buildings, etc.

Human Resource Capability 2005—represents expertise and operationalsupport that people offer the customer on behalf of the enterprise,sometimes direct and sometimes through an outsourcing arrangement.Operational support might include such activities as customer care andnetwork management, e.g. hot-line support, operator services, networksupport for a customer. Other such areas of expertise might includesales support, education & training, undertaking activities such as: IPapplication consulting, product education and training, businessimprovement consulting etc.

The Enterprise Capability 110 is shown as a “Parameter Defined” class.This means that the class has associated with it any number ofparameters that are used to capture the aspects and constraints of thecapabilities. Such a parameter may state for example that “email mailboxsize must be less than 1 gigabyte” or that “number of address bookentries must be less than 1000”. The parameters are used to express theboundaries of characteristics for potential product.

Product Component Fulfilment

Referring to FIG. 17, the Product Component Fulfilment (PCF) 1720 is a“Parameter Defined” class that represents a specialisation of anEnterprise Capability 110, bound by the parameter choices made from thecorresponding Component Selection 1715 when the Agreement is determinedand a Product Selection 1710 is made.

The Enterprise Capability 110 defines what the enterprise can provide,and when, and the Product Component 1705 represents what is offered tothe marketplace via the Marketplace Product 1700. The Product Selection1710 represents what is chosen in the Agreement (as a collection ofComponent Selections 1715) and the Product Component Fulfilment 1720 iswhat is actually provided.

This is best served by example.

Danny Granville visits the BT shop in order to buy a new answeringmachine. BT has several models on show and others in a productcatalogue. Danny has £100 to spend and chooses a top-of-the-rangedigital model with remote interrogation facility. The shop doesn't havethis particular model in stock, but agrees to fulfil Danny's orderwithin two weeks. One week later, Danny gets a Jiffy bag in the post inwhich is his new answering machine.

In the above example, BT's catalogues contain all the MarketplaceProducts 1700 that BT is making available to the public. Each answeringmachine type in the catalogue is a Marketplace Product 1700. Each typeof answering machine consists of the basic machine and other features(such as digital recording or remote interrogation), each of which areProduct Components 1705. The features that can be Product Components aredependent on the Enterprise Capabilities 110 that BT can command.Danny's selection of a specific answering machine type is the ProductSelection 1710. The individual choices for component options within thatselection are the Component Selections 1715. The Product ComponentFulfilments 1720 are the collection of things which arrived for Danny inthe post. These include the basic answering machine, the digitalrecording facility and the remote interrogation facility. Note thatProduct Component Fulfilment 1720 is a Parameter-defined Class, which inthis case will indicate the relationship between the three ProductComponent Fulfilments 1720 that were in the Jiffy bag.

Another example:

Terry Cooke wants to receive cable service. The cable provider, AcmeCable, is able to supply basic cable, a multitude of film channels, andthe Aquarium channel, which broadcasts the goings on within a tropicalfish tank 24 hours a day. Acme has a special deal where the subscriptionfor basic cable is bundled with the Aquarium channel for a mere $30 permonth. Terry loves to watch fish so he signs an Agreement with AcmeCable for this special deal. Acme Cable activates the cable line inTerry's home, which automatically gives him TV access to the basicchannels, and starts sending a feed for the Aquarium channel. Now, Terrycan watch fish all day long from the privacy of his own home.

In this example, the Enterprise Capability is the cable networkinfrastructure and all the entertainment channels that Acme Cable canprovide. The Marketplace Product is the “special deal” which consists ofa Product Component called “basic cable” and a separate ProductComponent called “Aquarium channel feed”, to which a Pricing Policy isattached of $30/month. It should be noted that there is a dependencybetween the Product Components 1705 here; one cannot receive theAquarium channel unless one also receives basic cable. The ProductSelection 1710 is the request for the “special deal” by Terry, withinthe Agreement with Acme Cable. Note: he makes two Component Selections1715 as part of this overall Product Selection 1710. Terry then receivestwo Product Component Fulfilments 1720, one for the basic cable feed toTerry's house and one for the additional Aquarium channel feed.

In the above example, the Aquarium channel must be treated as a separateProduct Component/Product Component Fulfilment, since if Terry decidedhe no longer wants to pay for this channel, it can be cancelled withoutdisrupting the basic cable feed. Thus, a Product Component Fulfilment1720 is the realisation of what each Product Component 1705 representswithin the context of a purchased Marketplace Product 1700.

Importantly, there is here a structure of dependency which can bothprevent an organisation from failing to deliver correct goods and fromfailing to record what goods were delivered. That is, Product ComponentFulfilment 1720 is dependent on Component Selection 1715 and EnterpriseCapability 110. In known data management systems, it is possible for anenterprise to deliver a product to a user which is different from theoriginal request, for instance because they only had an alternative instock. The order record however may easily be marked off as dealt with.However, the alternative product may not meet the user's requirementsand the delivery of a substitute may never be recorded in stock records.If the customer complains, the complaint could even be logged againstthe original order record, relating to the original product requested,and thus distort marketing data because the complaint should actuallyhave been logged against the substitute. Importantly, subsequent supportto the customer can be based on the wrong premise. An engineer may gowrongly equipped to the customer premises because the record for thatcustomer shows the wrong product description.

In embodiments of the present invention, it is not possible to enter arecord against product component fulfilment for a product that was notavailable or not requested. This is a direct consequence of thedependency of the Product Component Fulfilment 1720 class on ComponentSelection 1715 and Enterprise Capability.

In embodiment of the present invention, not only is the ProductComponent Fulfilment 1720 dependent on a current Enterprise Capability110 but it can be made dependent on a planned Enterprise Capability. Theclass definitions are listed below. It can be seen that the EnterpriseCapability 110 contains data for “Effective Date” and “Termination Date”while the Product Component Fulfilment 1720 contains date for“Availability Date”. Thus an instance of the Product ComponentFulfilment 1720 can be given an availability date which will either beimmediate or will be at a date in the future determined by the“Effective Date” of the Enterprise Capability supporting the ProductComponent Fulfilment 1720 instance. If the current date is already pastthe relevant “Termination Date”, the Product Component Fulfilmentinstance will show it to be unavailable. For instance the status mightshow “suspended”.

Dependency in this context means that it is not possible to instantiatean instance of a dependent class before there is a instantiated instanceof a class from which it is dependent. In database terms, it is notpossible to create a record in a table until reference has been made toanother table for a record which matches the dependency. An example ofthe effect this has in the user world is that of a user trying toinitiate a user session. Unless an Access & usage Rights Policy exists,which is met, the user is barred from initiating the user session (seebelow the description with reference to FIG. 19).

In the context of product fulfilment, the class dependencies describedabove mean that the following series of steps takes place:

-   -   i) A supplier decides to launch a new product on the market. To        do that, it is first necessary to instantiate in the data        management system an enterprise capability object 110 which may        have an effective date in the past, present or future (thus        accommodating planned infrastructure as well as existing        infrastructure). This first necessary step is subsequently used        by the data management system to ensure the new product can be        supported as of launch.    -   ii) Before launch, it is necessary to instantiate a marketplace        product object 1700 in the data management system. Because of        the class dependency, this is not accepted by the system until        it has located an existing enterprise capability object which        satisfies the marketplace product object prior to instantiation.        If there is such an enterprise capability object, the system        accepts the marketplace product object 1700 and the supplier can        now launch the product on the market. An example might be        Internet Services.    -   iii) A customer decides to buy the product. The customer and the        supplier come to an agreement about terms, such as price and        start date, and an instantiated agreement object 100 is entered        to the system.    -   iv) The marketplace product object 1700 will have generated a        set of dependent product components 1705 which represent choices        for the customer. For instance the Internet Services product may        contain the components WWW access, UseNet access and SMTP        access. A product component 1705 will identify one of these        components, say WWW access, plus a set of options within that        component, such as whether access is available via all sites or        via a selection and whether access is available all day or        between certain hours. In making an agreement, the customer        makes not just a product selection 1710 but also a component        selection 1715. For instance the customer may choose the product        “WWW access” with the components that it will be available at a        subset of sites and for the hours 6pm to 8am only. In the data        management system, this component selection 1715 is dependent on        the product components 1705 and can only thus be instantiated if        the system can locate a relevant product component 1705. The        customer's product selection 1710 includes an aggregation of the        component selections 1715 for the product.    -   v) The supplier will now want to deliver the customer's choice.        To record delivery on the system, it is necessary to instantiate        a product component fulfilment object 1720. This has dependency        on both the customer's component selection 1715 and the        enterprise capability 110. Hence, it is not possible to record        delivery of a product to the customer which wasn't related to        the customer's component selection 1715 or cannot be supported        by the enterprise.

A strength of the system described above is that there are at least twochecks made on enterprise capability. Support for products/services is aperennial problem for communication companies. In embodiments of thepresent invention, a first check is enforced when a marketplace productis launched. Although the enterprise capability doesn't have to be thereat day one, as long as there is planned capability, the product canstill be launched as long as the launch date instantiated in themarketplace product object 1700 is supported by the effective date inthe enterprise capability object 110. Importantly, a second check isenforced at a time when the scenario may be very different, that is,after a customer has responded to a product launch and the supplier isready to deliver a product to the customer. This may be some time afterthe product was first launched and the enterprise capability may havechanged significantly. For instance, the termination date instantiatedin a relevant enterprise capability object may have passed. If this isthe case, it is not possible to enter to the system an unsupportedproduct component fulfilment object 1720.

It is preferable that the product selection 1710 is dependent on therelationship between the agreement with a customer and a product. Thatis, an agreement which refers to a product.

It may be that a supplier is unable to deliver a product originallyselected by the customer and intends to enter a product componentfulfilment object 1720 which fails in its dependency on the componentselection 1715. This will be acceptable as long as an instantiatedagreement item 1410 could be satisfied by the substitute. To allow thesystem to deal with this, two instances of the product componentfulfilment object 1720 which point to each other need to be entered inthe system.

It can be important that there is an accurate entry in respect ofproduct component fulfilment 1720. For instance, it may be that acustomer wants a frame relay product. It may be found that the customerhas no sites supported by frame relay but has sites supported by SMDS.Although an instantiated agreement 100 for the customer may show thatthe substitution is acceptable, it is very important that an engineerproviding support is able to know that he is dealing with SMDS and canhave the correct equipment for a site visit. It is important that thesystem can make two references, one to the component selection 1715(what the customer ordered) and one to the product component fulfilment1710 (what was delivered).

The enterprise capability in the above description will comprise aseries of managed system elements and defined capacity. The arrows inFIG. 17 from the Product Component 1705 and the Product ComponentFulfilment 1720 are references to the managed system elements. In anexample of this in practice, a Marketplace Product 1700 might be PSTN(Public Switched Telephone Network) services. The supplier may haveinstalled 10,000 switches. At product launch, the product components1705 will point to all of the switches. However, a customer may need theservice at a single switch, for instance the Ipswich switch. Hence theProduct Component Fulfilment 1720 for this customer's order will bedependent on the Ipswich switch.

The presence of this dependency on the managed system elements allowsthe supplier to make decisions about where to launch new services (ieproducts). For instance, the ADSL product will need to be supported byADSL switches. A database of switches is available to or contained inthe enterprise capability 110. In the UK at present, the ADSL productcomponent 1705 will point to about 30% of those switches and the productcomponent fulfilment for a customer will probably point to just one ofthose switches. This prevents the supplier reaching agreement to supplythe ADSL product to a customer who simply cannot be supplied with it.

If there is no longer support for a product component, it will simplylose its reference and fail in its dependency. If in the example above,all the ADSL switches are closed down, the ADSL product components 1705will no longer be valid. This is standard database practice that oncethe last reference goes, it's flagged to the system that integrity hasbeen lost and the relevant product component will be deleted.

An advantage of embodiments of the present invention is that kit can bechanged without changing product definitions. For instance, if there hadbeen 300 ADSL switches available, recorded in the enterprise capability110, and 100 are closed, the product components 1705 dependent on ADSLswitches remain unchanged. The only thing that will change is that the300 references in the system which were previously between each ADSLproduct component 1705 and the switches recorded in the enterprisecapability 110 will drop to 200 references.

Dependencies of the type described above will take different forms indifferent database technologies. In database jargon, they will often bereferred to as “foreign keys”. Dependency as described is a particularform where one object can't exist without another existing first.

User vs. Customer

It is common practice in “real life” for the Customer and User of aservice to be different entities. For example, a company might beidentified as a Customer in an Agreement for a PC Helpdesk service butclearly it will be the individual employees that actually make use ofthe Helpdesk. Embodiments of the present invention therefore explicitlyseparate Customer from User in the model. A Customer is an AgreementRole within an Agreement that is associated with a specific Party. AUser is an entity that actually interacts with the Product ComponentFulfilment.

In the answering machine example above, Danny Granville is both theCustomer and User. As a Customer he enters into an Agreement with BT forthe purchase and provision of his chosen machine. He receives theProduct Component Fulfilments in the mail and may interact with them asa User. For example, he may set-up the time on the answering machine,may record an out-going message with the digital recording facility andmay interrogate the device remotely at some later time to pick up hismessages. However, Danny in the Agreement Role of Customer could haverequested that the machine be sent to his cousin Mortimer. In this case,Danny is the Customer and Mortimer will be the User, since Mortimer willnow have the interaction with the device that he receives in the mail.Note that in this example, Danny is granting rights to Mortimer to usethe answering machine.

Types of User

A User need not always be a person. The User may also be an organisationor a device, depending on nature of the Product Component Fulfilment.For example a CRON job (a Programme that is scheduled to run at regulartimes) that is collecting information from a database overnight would bethe User of the database.

These different types of User are represented by the sub-classes Human,Non-Human and User Group. A Human User is associated with a Party, ofsub-type Individual, but an Individual may be associated with one ormore Human Users. A Non-Human User is associated with one Managed SystemElement, but an MSE may be associated with one or more Non-Human Users.

A User Group is a set of one or more Users, that have a common set ofCredentials, interact with the exact same PCF and are administered as asingle User. A User Group may consist of any combination of Human Users,Non-Human Users and User Groups.

Credentials and Access & Usage Rights Policy

User/Customer Separation and the Relationship of a User with a ServiceFulfilment

Referring to FIG. 19, when a customer enters into an agreement with asupplier, the fulfilled product component 1720 (see above) may bepresented to a number of users 150. FIG. 19 shows the construction ofthe way in which users are related to the product component fulfilment(PCF) and the original customer/supplier agreement.

Each user 150 is granted rights to use the product component fulfilment1720, as determined in the agreement between customer and supplier whichresulted in the selected product component 1705 being fulfilled (seeabove). When the user uses the PCF 1720, a user-fulfilment relationship(UFR) 2220 is formed, consisting of the data for each user session 2200.The ability to create a user session is determined by the access andusage rights policy (A&URP) 2210 in force for that UFR 2220. Eachagreement between customer and supplier will contain one or moreagreement items 1410, which may refer to an A&URP 2210. The A&URP 2210determines the way in which the user interacts with the PCF 1720, as setout by the customer. The A&URP 2205 assesses the credentials of the userand the access-usage rights information 2210 of the PCF 1720, todetermine the policy for access and usage.

The use of this construction has a number of benefits to an enterpriseseeking to manage the data relating to customers, users and use of thefulfilled product components:

-   -   It allows data associated with the customer to be kept separate        from that of the user. In examples of supplying communication        services to large business there may be many users but only one        customer. For efficient business management, it is essential to        separate their concerns. For efficient data management, it is        essential to manage user data (which tends to be concerned more        with service elements and is transitory in nature) from customer        data (which tends to be concerned more with commercial elements        and is more long-lived).    -   While providing for separated customer and user concerns, it        allows the use of flexible business rules (via a policy class)        to ensure that users rights are governed by the contractual        agreement binding on the customer.    -   It allows for separate data management of the user from its        credentials. In fast-moving communication services, the        credentials may need to be managed in real time to determine        access rights on the fly.    -   It allows for separate data management of the PCF from the        elements of service which need to be assessed by the rights        policy. This allows for changes in operational capacity to be        reflected in the rights granted to users, without affecting the        overall service specification. This is essential in services        that share common resources and where demand fluctuates over        time.

The above is now discussed in more detail. In embodiments of the presentinvention, the commonly used terms of authentication and authorisationare modeled as the validation of a User's Credentials 2215 and theevaluation of business rules associated with the access and privilegespertaining to a User's interaction with a Product Component Fulfilment1720.

There are many different schemes that can be used to determine therights of a User 150 to make use of a Product Component Fulfilment 1720.These schemes may be based on who the User is, what role the User isplaying, what tokens the User possesses, or some combination of theseand other schemes. The security mechanism implemented is determined bythe type of scheme and the level of security required. For example,username/password or digital certificates can both be used to enforce ascheme based on User identity but one provides a greater level ofsecurity than the other. The variety of options means that the modelcannot prescribe the use of, or make assumptions about the type ofscheme or choice of mechanism that will be used in any particularsituation. To model this in a generic manner the following classes canbe defined: Access & Usage Rights Policy 2205, Credentials 2215 andAccess-Usage Rights Information 2210.

Access & Usage Rights Policy 2205

The Access & Usage Rights Policy is the set of business rules thatdetermine the rights of a User 150 to use a Product Component Fulfilment1720. This policy is established as a result of an Agreement. Forexample, a Customer has selected a 2 Mb Virtual Private Network, whichsupports up to 10 users. Of these 10 users, 2 will be enabled at thefull 2 Mb and the other 8 will be enabled at 0.5 Mb. The set of validuser profiles and their bandwidth allocation will form part of thePolicy Rules of the Access & Usage Rights Policy 2205. In addition tothis information it is likely that a username/password system will beused in the validation of the Credentials 2215. A complete entry in theAccess & Usage Rights Policy might then be “IF login=Joe Mercer ANDpassword=Happy THEN allow access at 2 Mb”. The Access & Usage RightsPolicy must be evaluated to allow the User 150 to access and use theProduct Component Fulfilment 1720.

The Access & Usage Rights Policy 2205 can be modified during thelifetime of the Agreement 100. This might be as a result of a revisionto the Agreement 100 but could also be modified by the Users 150themselves. An example of modifying Access & Usage Rights Policy is thehead of a household who is able to set the rights of the children toaccess channels on a Video-On-Demand service. Within the Access & UsageRights Policy 2205, there would be a Condition that grants the right toaccess a Product Component Fulfilment of a Policy Administration ProductComponent 1705, to a User 150 with the proper Credentials 2215. Accessto this PCF 1720 would give the User the ability to change certainConditions within the A & UR Policy 2205 governing the Video On Demandservice for other Users 150 within a specified grouping.

Credentials 2215

The Credentials 2215 of a User 150 represents all information about theUser 150 that is required by the Access & Usage Rights Policy 2205. Theinformation held depends on the type of rights determination scheme andauthorization/authentication mechanisms employed. In the VPN example,the User is identified via its account and password. The Credentials2215 of the User 150 would therefore comprise the username and thepassword of the User.

Access & Usage Rights Information

The Access & Usage Rights Information 2210 holds all informationrelating to the Product Component Fulfilment 1720 that is required bythe Access & Usage Rights Policy 2205. For example, an additionalcondition in the Access & Usage Rights Policy 2205 might be that a User150 cannot connect to the VPN if the total bandwidth being utilized bythe current Users is 90% of the agreed 2 Mb. The information about thetotal utilization would be held in the Access Rights Information 2210.

User-Fulfilment Relationship 2220 and User Session 2200

The User-Fulfilment Relationship (UFR) defines the association between aUser 150 and a Product Component Fulfilment 1720. Minimally, the UFR2220 describes the length of time that this association exists. The UFRcontains one or more User Sessions 2200, defining specific instanceswhen the User-Fulfilment Relationship 2220 is in use. Each User Session2200 may generate Events 115, which may be interpreted as Usage by theEvent Policy (see class descriptions).

For example, Shaun moves into a new apartment and enters into anAgreement 100 with the telephone company to activate the apartment'sphone line. In this example, the Product Component Fulfilment 1720 isthe activation of the phone line. The User 150 is the termination pointof the phone line, an MSE, located in Shaun's apartment. TheUser-Fulfilment Relationship 2220 exists as long as Shaun pays the billsor doesn't request that the line be de-activated.

A User Session object 2200, associated with the UFR 2220, is createdevery time the phone goes off-hook and a phone number is entered. So, ifShaun picks up the phone and calls his mother, a User Session object2200 is created.

Implementation Aspects

One option for implementation of a system according to an embodiment ofthe present invention is to implement an information repository whichprovides a set of information management services to the enterprise.This implementation is discussed in the following.

Referring to FIG. 20, the information model can be realized within animplemented infrastructure through the utilization of class and schemadefinitions. This utilization centres around two realization components:the IA Class Library 2300 and the Information Repository (IR) 2305.

The applications 2315 and network components 2320 of the infrastructure,collectively referred to as Apps, interact with the IA objects stored inthe Information Repository 2305 across an object communications bus2310. The objects that the Apps reference are compatible because theobjects are based on the class definitions from the IA Class Library2300. The IA Class Library, in turn, reflects a common informationdefinition that is used across the infrastructure, namely theInformation model 2325. The IA objects belong to the Infrastructure andcontain the rules that specify the details and extent of the integritythey require. These objects are deconstructed and the values are stored.When the objects are needed, the values are retrieved and the objectsare reconstructed.

The Information Repository Component Interface (IR Component Interface)2330 provides an object-oriented interface to the IA objects in theInformation Repository Component (IR Component) 2335. The Apps use theinterface to perform data manipulation functions against the datadefined by the Information model 2325. The IR Component 2335 knows inwhich Physical Data Store 2340 the data resides and translates thefunction requested into a request to the appropriate Physical Data Store2340 in the data stores native request language, such as SQL. Uponreturn of the request, the IR Component 2335 maps the result back to anobject-oriented response.

Two modes of service are offered though the IR Component Interface 2330:intelligent service and simple data persistence. With theintelligent-service mode, the IA classes are instantiated in the IRComponent 2335 and may be used in place through proxies. This promotessharing among Apps and decreases their size and complexity. The objectsmay also be mirrored in the App or even sub-classed to conform to thespecialized requirements of the App. The simple-data-persistence mode islimited to providing persistent storage and prompt retrieval ofindividual data values. This mode is intended to relieve Apps of thenecessity of managing private data storage.

IA Class Library 2300

The IA Class Library 2300 is the keystone for realizing the Informationmodel within the infrastructure. The class definitions from theInformation model 2325 (and shown in FIG. 1) are catalogued in the IAClass Library. These definitions are used to build the InformationRepository (IR) 2305 and are made available to the development communityto aid in the construction of infrastructure components 2320 and theadapters 2345 that allow applications to participate in theinfrastructure. This ensures that the classes used within theinfrastructure and the object-oriented IR 2305 are compatible, andguarantees interoperability.

The attributes and methods associated with the classes in the IA ClassLibrary 2300 constitute the IA information environment for theinfrastructure. This information is documented in an IA data dictionary.The class implementations are provided as a code library. The servicesassociated with the IA Class Library 2300 need to be supported duringthe design and development of the infrastructure to make the concept ofthe IR feasible. IA Class Library services include the provision of:

Documentation Standards Manuals Source Code Library Source UtilizationSource Complied Code XML Definitions

The scope of the IA Class Library 2300 is limited to the Informationmodel. Material regarding the development environment, OA&M, andinstallation is excluded as is material that is the exclusive concern ofthe Apps.

Information Repository 2305

The Information Repository encompasses and unifies, in so far aspractical, all the data stores 2340 associated with the physicalinfrastructure that implements the Information model. The IR 2340 isresponsible for insulating the other architecture components from thephysical implementation of the information.

The architecture of the IR envisions two data situations. In the first,the data are directly associated with objects in the model 2325 (andshown in FIG. 1). Object persistence and build operations are done bythe IR Component 2335, which also executes and enforces the integrityrules. Since the IR Component has access to the methods associated withthe objects, it is in a position to offer many services in addition tomaintaining integrity.

In the second situation, the data belongs to and is managed by the Apps2315,2320. This data needs to be reconciled with the IA objects or withthat of other Apps. As one cannot forbid Apps from communicatingdirectly with one another, the best one can do is to provide a set ofuseful services, such as a data-location registry containing a protocoland data-model translation or a central control point for theenforcement of whatever integrity rules the Apps supply.

To accommodate these two situations, the IR 2305 has two differentaspects:

-   -   Information Repository Component (IR Component) 2335 that        provide storage, retrieval, direct interaction, and other data        services through the IR Component Interface 2330 for objects        defined in the Information model 2325. This corresponds to the        first situation.    -   The Information Repository Service (IR-Service) that provides        access to services associated with the Information Repository        for Supplementary Data Stores (SDS). A SDS is a data store that        may only be accessed through the applications that own it.        Examples include data services provided by other components of        infrastructure, or customer databases owned by third-party        applications running on the infrastructure. This corresponds to        the second situation.

A fundamental property of the Information Repository 2305 is that thereare no back doors to databases. A database is controlled by theapplication that owns it and may only be accessed and coordinated withother databases through that application.

The Information Repository Component 2335

The IR Component 2335 plays a central role in realizing the Informationmodel 2325 and shown in FIG. 1. It is responsible for insulating theInfrastructure Components 2320 from the physical data stores 2340, whichprovide the persistent storage needed by the Infrastructure. The IRComponent 2335 accomplishes this by mapping the data attributes of theclasses to the data elements in the physical storage. Both the classdefinitions and the schema definitions are used by the IR Component 2335to create the mappings.

In the intelligent-service mode, the IR Component can providereferential integrity, run business rules, take part in transactions,administer and maintain policies and profiles, provide access throughproxies, and otherwise take advantage of the behavior and intelligencebuilt into the IA classes. This is because it has complete knowledge ofthe public instance variables, associations, public methods, and theAPIs the IA classes expose to proxies through IDL (Interface DefinitionLanguage) interfaces. The proposed IR Component 2335 facilities tosupport the intelligent-service mode include:

Storage Access Administration Database Management Security AuthorizationIntegrity - Transactions Audit Trails History Distribution LoadBalancing Caching Notification Metrics (& Reports) Maintenance

The IR Component also supports facilities for thesimple-data-persistence mode. These facilities, such as access controland audit trails, are those that can be implemented by attachingmetadata to the values but require no knowledge of the relationshipsamong stored values.

The Information Repository Services

The purpose of the IR Services is to assure that the data associatedwith the Infrastructure are consistent, to the extent that is practicalgiven the capabilities of the underlying APIs of the Apps 2315/2320 thatmanage Supplementary Data Stores. The IR-Service provides a centralframework based on the IA classes for maintaining InfrastructureInformation that is outside the purview of the IR Component 2335. Theneed for doing this arises when independently developed databases areintegrated into the Infrastructure. Synchronization becomes an issue forthe following situations:

-   -   1. The data in the App's database changes, and the IR Component        database needs to be updated.    -   2. The data in the IR Component database changes, and the App's        database needs to be updated.    -   3. The data in an App's database changes, and the data in        another App's database needs to be updated.    -   4. An App needs to read data from the database of another App.

These interactions require a knowledge of the data items in the Apps,the APIs (and protocols) of the Apps 2315/2320, the relationships amongdata items that need to be preserved in the Apps, and the actions thatneed to be taken to preserve integrity. To support these interactions,the Information Repository Service will need to provide:

-   -   A common data language (CDL) for controlling and executing data        exchange. A language such as XML is sufficient for exchanging        data, however one may need additional language facilities to,        for example, coordinate transactions.    -   A mapping facility to equivalence the names the different Apps        use to designate the same variable.    -   A registry that identifies the App(s) that uses a variable. The        registry may contain other information such as access        permissions.    -   Containers for the logic required to implement the interaction.        Sub-classes of the IA classes are the containers of choice.

It will be understood that, in use, one of the purposes of a datamanagement system built according to the data structures described aboveis to control the generation of information, for instance for output toa user or other system. In particular, it controls the sources for thatinformation output and the way in which the information output isconstructed. It introduces a time factor so that an information outputmay be different if constructed before a certain time rather than aftera certain time and, in the case of a planned enterprise capabilitysupporting product component fulfilment, it provides flexibility in thecontent of the information output in relation to time.

Within the data management system, the classes and their dependenciesact in a manner analogous to network routing. If data is input to thesystem, the data management system effectively routes it to entitieswithin the system which require the data, which will act on the data,and which together will generate an output dependent on the input data.

Class Dictionary

The class dictionary provides definitions for each of the object classesgiven in the model described above.

-   -   1. The Class Name column of the table contains the name of the        class as it appears in the model.

Policy class names, designated in the diagrams with <<Policy>>, are initalics. Parameter Defined class names, designated in the diagrams with<<Parameter Defined>>, are underlined.

-   -   2. The Definition column contains a short explanation of the        class. This may include an example and potential attributes.    -   3. The attributes assigned to each class represent a key set and        not the definitive set. It is expected that in further        refinements to this model, additional attributes may be        identified.    -   4. All sub-classes inherit the attributes of the super-class.    -   5. The Notes column contains additional clarifying notes about        the class, e.g. indicating that it's a sub-class of another        listed class or that it is a placeholder.    -   6. All information classes have the following methods available:        create—establishing an instance of the class; read—retrieving        the values of the attributes of the instance; update—changing        one or more values of the attributes of the instance; and        delete—removing the instance of the class.

Class Name Definition Notes Access & The set of conditions and actionsthat For details on policy Usage Rights determine the rights of a Userto class behaviour, see Policy use a Product Component Fulfilment.description above. This policy is established as a result of anAgreement. Access- Information about a Product Compo- Sub-classes areUsage nent Fulfilment in the context of required to model Rightsavailable capacity that is to be used the information Information inevaluating an Access & Usage relevant to each Rights Policy. Forexample, total Product Component bandwidth utilised, the total mail-Fulfilment. box space used, and number of users. Activity Represents adiscrete unit of work A constituent class which may be carried out by aof Activity Program. person or a machine. This class may be Attributes:extended through Name the use of sub- Start date classes. Identified EndDate sub-classes are Description Human Activity and Required EffortMachine Activity. Dependency Associated Costs Required materialsActivity This is an abstract class that defines An interaction forInteraction the relationship of one Activity to the Activity - anotherActivity. For example one Activity relation- Activity may negate theneed for ship. another. Attributes: Priority Status Activity A plannedcollection of Activities This class may be Program which realise thecapabilities of extended through the enterprise the use of sub-Attributes: classes. Identified Program Name sub-classes are ProgramDescription Order-Based Pro- Effective Date gram, and Non- TerminationDate Order Program. Activity This is an abstract class that defines Aninteraction for Program the relationship of one Activity the ActivityPro- Interaction Program to another Activity Program. gram - ActivityPro- For example one Activity Program gram relationship. may depend uponanother one. Attributes: Priority Status Agreement A commercialarrangement between This class may be at least two Parties. extendedthrough Attributes: the use of sub- Effective Date classes. IdentifiedTermination Date sub-classes are Bid, Signed Agreement Date Contract,and Order Description Status Agreement The designation of a Party tounder- A RoleAssignment Assignment take the responsibilities of an forthe Party - Agreement Role. Agreement Role Attributes: relationship.Effective Date Termination Date Status {pending, active, tempo- rary, .. . } Agreement This is an abstract class that defines An interactionfor Interaction the relationship of one Agreement to the Agreement -another Agreement. For example an Agreement Agreement may be revised andsuper- relationship seded by another one. Agreement A line item withinan Agreement A constituent class Item indicating the selection ofMarket- of Agreement. place Product to be purchased/ supplied.Attributes: Quantity Agreement A responsibility that is defined Thisclass may be Role within an Agreement e.g. signatory, extended throughcustomer, guarantor the use of sub- Attributes: classes. Identified Typesub-classes are Role Scope (responsibility) Customer, Supplier,Importance {mandatory, optional} Guarantor, and Distributor. ComponentRepresents the Product Component For details on Selection selectedwithin a Product Selection. parameter defined It is this ComponentSelection which class behaviour, see is fulfilled by a Product Componentdescription above. Fulfilment. Attributes: Date Requested Date FulfilledContained Characterises the relationship be- Association Class Componenttween a Marketplace Product and for the Marketplace its ProductComponents Product - Product Component relationship Contract A legallybinding agreement to pro- A sub-class of vide services and/or goods at aAgreement. stated price. Attribute: Renewal Notification Date CredentialInformation about a User that is to be This class may be used inevaluating an Access & extended through Usage Rights Policy. Theinformation the use of sub- held depends on the particular secu- classesto model the rity scheme employed. particular security Attributes:scheme employed. Effective Timestamp Potential sub-classes TerminationTimestamp are Password, Cer- Status tificate, and LogName. Customer Arole defined for an Agreement in A sub-class of which the Party actingin this role Agreement Role. purchases services or goods from an otherParty. Customised A type of Marketplace Product which A sub-class ofProduct has been tailored for a specific Marketplace Prod- Party, groupof Parties or a certain uct. Market Segment. Attributes: ModificationDate Effective Date Termination Date Ramifications Distributor A roledefined for an Agreement. The A sub-class of Party acting in this rolemar- Agreement Role. kets and sells services and goods to other Parties.For example, a whole- saler. Enterprise Represents all the product- Thisclass may be Capability forming and product-impacting extended throughcapabilities of the enterprise. the use of sub- Attributes: classes.Identified Capability Name sub-classes are Description InfrastructureStatus {test, alpha, GA, . . . } Capability, Support Effective DateCapability, and Termination Date Consultation Capability. For details onparameter defined class behaviour, see description above. Fulfilment Acollection of events and troubles This class would Performance that arecollected over a set period provide the for the purpose of evaluatingthe information from performance of a Product Component which reportswould Fulfilment against availability and be generated. quality metricsoutlined by the Agreement Service Level Guarantee. Attributes: DateDescription Period Generic A standard (vanilla) product offered Asub-class of Product to the marketplace. Marketplace Prod- uct.Guarantor A role defined for an Agreement. The A sub-class of Partyacting in this role guarantees Agreement Role. payment for purchases ofproducts or services by another Party. Human An Activity that isperformed by a A sub-class of Activity human. Activity. Human Theresponsibility for managing an A RoleAssignment Activity Activity forthe Activity/ Role Party relationship. Human Represents the peopleavailable in A sub-class of Resource the enterprise with specialisedEnterprise Capabil- Capability expertise, for customer assist- ity anceetc. Attributes: Name Description Type (Online, on premise, helpdesk)Class (Premium, Standard, Best Effort) Level Availability (24 × 7 × 52,8 × 5) Human A role carried out in support of the An RoleAssignmentResource Enterprise Capability. for the Human Capability ResourceCapabil- Role ity/Party relation- ship. Human The responsibility forcarrying out a An association class Resource specialist role in supportof the for Human Resource Capability Enterprise Capability. Capabilityand Assignment Party. Human User A User that is associated with the Asub-class of User. Individual subclass of Party. Individual Uniqueidentifier for that individual. A sub-class of Party. See the Party &Party Identifier classes for details. Infrastruc- A distinguishablecollection of ture Managed System Elements which support the delivery ofthe Infrastructure Capability. e.g. the PSTN Platform which sup- portsand delivers “telephony” capabilities. Attributes: Name DescriptionOwner Status Infrastruc- Defines the specific capabilities A sub-classof ture Capabil- that an Infrastructure can deliver. Enterprise Capabil-ity ity. For details on parameter defined class behaviour, seedescription above. Logical An abstract class that represents anSub-class of Logical Device abstraction or emulation of a hard- Element.From the ware entity that may or may not be DMTF CIM v2.2 realised inphysical hardware. Any model. Sub-classes characteristics of a LogicalDevice include Power are used to manage its operation or Supply, Modem,configuration contained in, or Controller, Printer, associated with, theLogical Device Battery, USB De- object. E.g. support for paper vice,Alarm Device, sizes and detection of errors in a Scanner, Sensor,printer is modeled in a Logical Cooling Device, Device. Media AccessAttributes: Device, User as defined by DMTF CIM v2.2 Device, NetworkAdapter, Media Transfer Device, Logical Port Logical The base class ofall components of a Sub-class of Element system that represent abstractfunc- Managed System tionality, such as, files, processes or Element.From the other system capabilities that can be DMTF CIM v2.2 modeled asa Logical Device. model. Sub-classes Attributes: include Process, asdefined by DMTF CIM v2.2 Logical File, Service Access Point, FileSystem, Directory, Device File, Data File, Service, Software Feature,Software Element, Operating System, System, Computer System, StorageLibrary, Logical Device Managed This is the base class for the systemFrom the DMTF System element hierarchy. Membership CIM v2.2 model.Element Criteria: Any distinguishable Sub-classes include (MSE)component of a system is a candidate Logical Element and for inclusionin this class. Examples: Physical Element. software components, such asfiles; devices, such as disk drives and controllers; and physicalcomponents such as chips and cards. MSEs may be comprised of other MSEsAttributes: as defined by DMTF CIM v2.2 must also include ‘Capacity’ MSEA role assigned to a person to A RoleAssignment Assignment manage aManaged system Element. for the MSE/Party relationship. MSE This is anabstract class that An interaction for Interaction defines therelationship of one the MSE - MSE Managed System Element to anotherrelationship Managed System Element. For example one Managed SystemElement may be substituted for another one. MSE Role A role assigned toa person or An association class machine to manage an activity. forParty and MSE. Marketing A Marketing Campaign is the plan Campaign fordelivery of a specific message to a segment of the community usingsuitable media. Attributes: Name Description Start Date End DateMarketplace A group of one or more Product This class may be ProductComponents offered together and extended through priced as one unitaccording to the use of sub- Product Price Policy classes. IdentifiedAttributes: sub-classes are Name Generic Product and DescriptionCustomised Product. Introduction Date Sales Discontinuation Date SupportDiscontinuation Date Marketplace This is an abstract class that definesAn interaction for Product the relationship of one Marketplace theMarketplace Interaction Product to another Marketplace Product - Market-Product. For example one Market- place Product place Product may besubstituted relationship for another one. Marketplace A responsibilitythat is defined for a A constituent class Product Role MarketplaceProduct. e.g. product of Marketplace manager, support manager Product.Attributes: Role Name Type Role Function Importance {mandatory,optional} MPP The designation of a Party to under- An RoleAssignmentAssignment take the responsibilities of a Market- for the Party - placeProduct Role. Marketplace Product Attributes: Role relationship.Effective Date Termination Date Status {pending, active, tempo- rary, .. . } Non-Human A User that is not human. For ex- A sub-class of UserUser ample, a telephone line or a system element. Non-Order- A type ofActivity Program that A sub-class of Based delivers enhancements toEnterprise Activity Program. Program Capability which cannot be directlyassociated with a product selection. For example, the replacement ofcopper networks with fibre or Year 2000 activities. Organisation A groupof Individuals that functions A sub-class of as one autonomous unit forsome pur- Party. This class pose or work. may be extended Attributes:through the use of Name sub-classes. Some Function Description potentialsub- classes are House- hold, Corporation, Government Agency, andNon-profit. Organisation The designation of a Member to A RoleAssignmentAssignment undertake the responsibilities of an for the Member -Organisation Role. Organisation Role Attributes: relationship. EffectiveDate Termination Date Status {pending, active, tempo- rary, . . . }Organisation A responsibility that is defined A constituent class Rolewithin an Organisation e.g. vice- of Organisation. president, manager,engineer, mem- ber. Attributes: Role Name Type Role Scope(responsibility) Consideration {mandatory, optional} Party Party is anabstract class that encom- Sub-classes include passes both Organisationand Individ- Individual and ual. Organisation. Attributes: Party IDParty Name Legal Entity Status {no, yes} Legal Entity Date CommerceCredential Credit Bureau Score Credit Bureau Score Date Credit BureauName Party The ways of identifying a Party, May also include Identifierincluding both unique and non-unique credentials that a identifiers.party must have to Names be able to engage in commerce, such as tax ID,DUNS Number, SIC Code, Tax Exemption, mother's maiden name. PhysicalThis class describes system compo- A sub-class of Element nents thathave distinct physical Managed System manifestations Note that it isElement. From the possible for a single Card - which DMTF CIM v2.2 is atype of Physical Element - model. Sub-classes to host more than oneLogical include Physical Device. The card would be repre- Link, Physicalsented by a single Physical Element Connector, Physical associated withmultiple Logical Component, Physi- Devices. cal Package, Card,Attributes: Physical Frame, as defined by DMTF CIM v2.2 Chassis, Rack,Physical Media, Chip Product A generalised classification of Categoryproduct offered into the marketplace by market segment and/or the natureof the service e.g. IP Services, Telephony, Application Hosting.Attributes: Classification Type Description/Definition Product Acohesive unit of a deliverable A constituent class Component productthat has business and/or of Marketplace technical meaning (e.g. emailProduct. A depend- service, address book) ent class on Attributes:Enterprise Capabil- Name ity. For details on Description parameterdefined Status {alpha, beta, GA, . . . } class behaviour, seedescription above. Product Represents the delivered product Aconstituent class Component component. of Product Selec- FulfilmentAttributes: tion. A dependent Name class on Product DescriptionComponent and Status {active, suspended, . . . } Enterprise AvailabilityDate Capability. For details on parameter defined class behaviour, seedescription above. Product This is an abstract class that defines AnInteraction for Component the relationship of one Product the ProductCompo- Fulfilment Component Fulfilment to another nent Fulfilment -Interaction Product Component Fulfilment. Product Component Attributes:Fulfilment relation- Effective Date ship. Termination Date StatusProduct This is an abstract class that defines An Interaction forComponent the relationship of one Product the Product Compo- InteractionComponent to another Product nent - Product Component. Componentrelation- Attributes: ship. Effective Date Termination Date StatusProduct This is an abstract class that defines An interaction forInteraction the relationship of one Marketplace the Marketplace Productto another Marketplace Prod- Product - Market- uct. place ProductAttributes: relationship. Effective Date Termination Date Status ProductRepresents the Market Place Product An association class Selectionselected in the Agreement. for the Marketplace Attributes: Product -Agree- Date Requested ment Item relation- Date Fulfilled ship ProductDefines an allowed substitution of A sub-class of Prod- Substitution oneMarketplace Product for another uct Interaction Marketplace Product.Supplier A role defined for an Agreement. Sub-class of The Party actingin this role pro- Agreement Role. vides services or goods to anotherParty. User An entity that is authorised by an A constituent classAgreement to register with and use of User Group. the Product ComponentFulfilment(s) This class may be covered by the Agreement. That extendedthrough entity may be associated with an the use of sub- individual, anorganisation, or a classes. Identified managed system element. (see sub-sub-classes are User classes). Group, Human Attributes: Use, and Non-User Identification Human User. Effective Date Termination Date UserGroup A set of one or more Users that A sub-class of User. have a commonset of Credentials, interact with the same Product ComponentFulfilments, and are administered as a single User. A User Group mayconsist of any combination of Human Users, Non- Human Users, and UserGroups. Attributes: Name Description Member Criteria User SessionInformation about a specific User A constituent class engagement with aProduct Compo- of User-Fulfilment nent Fulfilment. Relationship.Attributes: Begin Timestamp End Timestamp Termination Reason StatusUser- Information about a User's associa- An association classFulfilment tion with a Product Component for the User - Prod-Relationship Fulfilment. uct Component Attributes: Fulfilment relation-Registration Date ship. Termination Date Status {active, suspended, . .. }

1. A data management system, which receives and processes data inrelation to one or more products, and records fulfilment of customerorders in respect of a generated product description, the systemcomprising: an input which receives-product selection data; amarketplace product store which stores marketplace product definitions;a product selection store which stores data defining a selection of oneor more products from the marketplace product store; an enterprisecapability store which stores data defining capability of an enterprisein relation to supply of one or more products; and a product fulfilmentdata store which stores one or more product descriptions and datarelated to the one or more product descriptions, the related datarepresenting an event already done to fulfill a customer order; anassociation data store storing association data associating each productdescription with specified data in said enterprise capability store; anda product fulfilment data store controller arranged in operation tostore a product description and related data representing an eventalready done to fulfill the customer order in said product fulfilmentdata store only when said enterprise capability store includes thespecified data associated with said product description by saidassociation data so that storage of the product description and therelated data in the product fulfilment data store is prevented when saidenterprise capability store does not include the specified data.
 2. Asystem according to claim 1 wherein the specified data in the enterprisecapability store relates to equipment necessary to support provision ofa product identified in the product description.
 3. A system accordingto claim 2 wherein a product description comprises date information, atleast one set of data stored in the enterprise capability storecomprises said specified data together with availability date data, andthe system reviews the availability date data against the dateinformation, such that a valid product description is dependent oncompatibility between the availability date data and the dateinformation.
 4. A system according to claim 3 wherein said availabilitydate data may be both compatible with the date information and in thefuture at the time that a product description is loaded to the productfulfilment data store.
 5. A system according to claim 1 wherein theassociation data is updated in response to updates to the specified datain the enterprise capability store.
 6. A system according to claim 1,wherein the specified data in the enterprise capability store comprisesidentifiers for instances of apparatus available to support a productidentified in a product description.
 7. A system according to claim 6wherein the specified data in the enterprise capability store is updatedand consequent changes made to data referencing said specified data. 8.A system according to claim 1 wherein said association data furthercomprises data associating each product description with specified datain said product selection store; and said product fulfilment data storecontroller is further arranged in operation to store a productdescription in said product fulfilment data store only when said productselection stored includes the specified data associated with saidproduct description by said association data.
 9. A method of managingdata relating to product provision in relation to supportingcapabilities, which method comprises: storing marketplace productdefinitions in a marketplace product store; receiving product selectiondata in relation to stored marketplace product definitions; storing datadefining a selection of one or more products from the marketplaceproduct store in a product selection store, in response to one or morereceived inputs; storing data defining capability of an enterprise inrelation to supply of one or more products in an enterprise capabilitystore; storing one or more product descriptions and data related to theone or more product descriptions, the related data representing an eventalready done to fulfill a customer order in a product fulfilment datastore; generating association data associating each product descriptionin the product fulfilment data store with specified data storable in theenterprise capability store; and selectively storing a productdescription and related data representing an event already done tofulfill the customer order in said product fulfilment data store byexamining said association data to identify said associated specifieddata, and storing said product description and related data representingan event already done to fulfill the customer order only on saidspecified data being found in said enterprise capability store so thatstorage of the product description and the related data in the productfulfilment data store is prevented when said enterprise capability storedoes not include the specified data.
 10. A system according to claim 1wherein said association data further comprises data associating eachmarketplace product definition with specified data in said enterprisecapability store; and the system further comprises a marketplace productstore controller arranged in operation to store a marketplace productdefinition in said marketplace product store only when said enterprisecapability store includes the specified data associated with saidmarketplace product definition by said association data.
 11. A systemaccording to claim 10 wherein any marketplace product definition storedin the marketplace product store is deleted in the event that tspecified data for that marketplace product definition is no longerstored in the enterprise capability store.
 12. A data management system,which receives and processes data in relation to one or more products,and recording fulfilment of customer orders in respect of a generatedproduct description, the system comprising: an input which receivesproduct selection data; a marketplace product store which storesmarketplace product definitions; a product selection store which storesdata defining a selection of one or more products from the marketplaceproduct store; an enterprise capability store which stores data definingcapability of an enterprise in relation to supply of one or moreproducts; and a product fulfilled data store which stores one or moreproduct descriptions; an association data store storing association dataassociating each product description with specified data in saidenterprise capability store; and a product fulfilled data storecontroller arranged in operation to store a product description in saidproduct fulfilled data store only when said enterprise capability storeincludes the specified data associated with said product description bysaid association data so that storage of the product description in saidproduct fulfilled data store is prevented when said enterprisecapability store does not include the specified data associated withsaid product description.
 13. A system according to claim 12 wherein thespecified data in the enterprise capability store relates to equipmentnecessary to support provision of a product identified in the productdescription.
 14. A system according to claim 13 wherein a productdescription comprises date information, at least one set of data storedin the enterprise capability store comprises said specified datatogether with availability date data, and the system reviews theavailability date data against the date information, such that a validproduct description is dependent on compatibility between theavailability date data and the date information.
 15. A system accordingto claim 14 wherein said availability date data may be both compatiblewith the date information and in the future at the time that a productdescription is loaded to the product fulfilled data store.
 16. A systemaccording to claim 12 wherein the association data is updated inresponse to updates to the specified data in the enterprise capabilitystore.
 17. A system according to claim 12, wherein the specified data inthe enterprise capability store comprises identifiers for instances ofapparatus available to support a product identified in a productdescription.
 18. A system according to claim 17 wherein the specifieddata in the enterprise capability store is updated and consequentchanges made to data referencing said specified data.
 19. A systemaccording to claim 12 wherein said association data further comprisesdata associating each marketplace product definition with specified datain said enterprise capability store; and the system further comprises amarketplace product store controller arranged in operation to store amarketplace product definition in said marketplace product store onlywhen said enterprise capability store includes the specified dataassociated with said marketplace product definition by said associationdata.
 20. A system according to claim 19 wherein any marketplace productdefinition stored in the marketplace product store is deleted in theevent that specified data for that marketplace product definition is nolonger stored in the enterprise capability store.
 21. A system accordingto claim 12 wherein said association data further comprises dataassociating each product description with specified data in said productselection store; and said product fulfilled data store controller isfurther arranged in operation to store a product description in saidproduct fulfilled data store only when said product selection storedincludes the specified data associated with said product description bysaid association data.
 22. A method of managing data relating to productprovision in relation to supporting capabilities, which methodcomprises: storing marketplace product definitions in a marketplaceproduct store; receiving product selection data in relation to storedmarketplace product definitions; storing data defining a selection ofone or more products from the marketplace product store in a productselection store, in response to one or more received inputs; storingdata defining capability of an enterprise in relation to supply of oneor more products in an enterprise capability store; storing one or moreproduct descriptions in a product fulfilled data store; and generatingassociation data associating each product description in the productfulfilled data store with specified data storable in the enterprisecapability store; and selectively storing a product description in saidproduct fulfilled data store by examining said association data toidentify said associated specified data, and storing said productdescription only on said specified data being found in said enterprisecapability store so that storage of the product description in saidproduct fulfilled data store is prevented when said enterprisecapability store does not include the specified data.